dr Zbigniew Olejniczak
Departament Informatyki 
Ministerstwo Gospodarki, Pracy i Polityki Społecznej

Kierunki rozwoju systemu informatycznego PULS

System informatyczny dla urzędów pracy został zaprojektowany w 1996 r. i wykonany w technologii, i na takich rozwiązaniach systemowych, które ówcześnie były obiecujące. Minione 6 lat zweryfikowały założenia, przyniosły potężny bagaż doświadczeń, pozwoliły zbudować (a raczej rozszerzyć) z pomocą Użytkowników nowe wymagania. Trzeba pamiętać, że system PULS, poza tym, że zaistniał, stworzył nową jakość jeszcze pod innym względem: zintegrował w miarę, w jednolitą strukturę informatyczną obieg informacji w urzędach pracy i "zainspirował" standaryzację struktury organizacyjnej.
Jeżeli można tak stwierdzić, to słuszne jest określenie: system PULS ucywilizował informatykę w urzędach pracy, stworzył nową jakość teleinformatyczną. To, że teraz jest już nieco przestarzały i coraz częściej jego rozwój natrafia na ograniczenia technologiczne w niczym nie umniejsza sukcesu, jakim było wdrożenie SI PULS w urzędach pracy. 
Dzisiaj jesteśmy w sytuacji, gdy uzasadnione jest najważniejsze pytanie: w jaki sposób przystosować rzeczywistość informatyczną służb zatrudnienia do nowych wymagań Użytkowników, spożytkować nowe rozwiązania technologiczne, nadążyć za standardami europejskimi?
Wydaje się, że realnie istnieją dwie drogi: intensywna modyfikacja i modernizacja SI PULS, albo budowa od podstaw nowego systemu. Nowy, od podstaw nie znaczy taki, który zaprzepaści istniejące zasoby informacji i umiejętności Użytkowników. Nie problem w formatkach ekranowych, a w tym, co się kryje "pod spodem", czyli jakiej technologii używamy. Nad zarysowanymi powyżej dylematami należy się zastanowić i to bardzo szybko, a czas zastanowienia jest krótki. Najlepiej, żeby ten czas jeszcze był, bowiem zmiany w rzeczywistości ustrojowej postępują niezwykle szybko. Trwają prace nad ustawą o zatrudnieniu, nad ustawą o świadczeniach na rzecz rodziny, nad ustawą o pomocy społecznej ..., intensywnie rozwijają się prace w programie IDA 


1. Beneficjenci systemu, partnerzy i otoczenie

System Urzędów Pracy i jego otoczenie zmieniły się w minionych latach na tyle, że wymaga to nowego spojrzenia na współpracę z otoczeniem, procesy wewnętrzne, itp. Lista beneficjentów systemu jest w zasadzie ta sama: osoby bezrobotne i poszukujące pracy, pracodawcy, ale istotnej zmianie uległo otoczenie urzędów, i to zarówno bliskie jak i zewnętrzne. Powstały nowe instytucje samorządowe, rozwinął się rynek usług komercyjnych. W rozważaniach nad daleko idącymi zmianami trzeba pamiętać, że sojuszników i przeciwników zmian najłatwiej doszukać się w najbliższym otoczeniu. Jedni w zmianach mogą doszukiwać się szans na poprawę warunków pracy, inni mogą obawiać się zagrożenia dla aktualnego, własnego stanu posiadania (zmiana organizacji może znaczyć utratę zatrudnienia) i wówczas taka postawa stanowi element ryzyka dla projektowanych zmian.
Lista beneficjentów systemu i partnerów jest długa, poniżej poddano krótkiej charakterystyce najważniejszych z nich. Dodatkowo wskazano na te problemy, które rodzą się we współpracy z daną grupą.

· Klienci urzędów pracy
Klientami urzędów pracy są bezrobotni oraz osoby posiadające pracę, jednak z różnych względów poszukujący zatrudnienia innego, bądź dodatkowego. Szczegóły wskazujące na to, kto dokładnie może być klientem urzędu pracy oraz na jakie usługi może liczyć, zawarte są w ustawie o zatrudnieniu. Trzeba przyjąć, że główną potrzebą większości bezrobotnych, jest jak najszybsze uzyskanie zatrudnienia. W tym urzędy mogą tylko częściowo pomóc (liczba ofert pracy, system wymiany ofert). Pamiętajmy jednak także, że 80% osób zarejestrowanych nie posiada prawa do zasiłku, a wśród nich jest grupa osób, dla których liczy się posiadanie opłaconych składek na ubezpieczenie zdrowotne. 
Patologią, o której głośno się mówi jest to, że wśród zarejestrowanych bezrobotnych znajdują się i tacy, którzy posiadają stałe zatrudnienie, i stały dochód, jednak wykonują pracę "na czarno", a zatem nie płacą podatków,  i kosztują swoich pracodawców o wiele mniej, a jednocześnie nie tracą uprawnień do świadczeń, na których składki odprowadzają urzędy pracy. Nie potrafimy, jak na razie zbudować skutecznego zabezpieczenia przeciwko temu procederowi.
W powszechnej świadomości utarło się, że za pośrednictwem urzędów pracy zatrudnienie mogą uzyskać jedynie osoby słabiej wykształcone, starające się o niżej płatne posady. Do rejestracji zgłaszają się jednak również osoby w miarę dobrze sytuowane, które znalazły się bez zatrudnienia, w związku z problemami ich dotychczasowych pracodawców. Dla uzupełnienia kategorii klientów dodajmy osoby w wieku przedemerytalnym, absolwentów, ... Czy można zbudować system wsparcia uwzględniający różne grupy klientów i odporny na spekulacyjne zachowanie, niektórych klientów?
Bezrobotni kontaktują się z właściwymi miejscowo urzędami pracy bądź ich filiami (rejestracja, potwierdzanie gotowości do pracy). Obowiązki te są jednak dla nich uciążliwe, a jest to spowodowane przyczynami: 
- czasowymi - znaczne oddalenie miejsca zamieszkania od siedziby urzędu,
- finansowymi - konieczność ponoszenia opłat przejazdów z własnych środków, co dla grupy najuboższych stanowi duży wydatek. 
Część z osób, które znalazły się w sytuacji bez zatrudnienia, już dzisiaj traktuje urząd pracy, jako pośrednika w załatwieniu wszelkich formalności (ZUS, Kasa Chorych), w jednym miejscu. Dzięki temu oszczędzają czas, który mogą przeznaczyć na samodzielne poszukiwanie pracy. Można sarkastycznie stwierdzić, że bez własnej woli urzędy pracy świadczą usługi, 
o których nie ma śladu materialnego w ustawie: być pośrednikiem w załatwianiu "spraw urzędowych" swoich bezrobotnych, ale spoglądając w przyszłość warto zapytać: dlaczego klient urzędu nie mógłby właśnie w jednym miejscu załatwiać swoich spraw "urzędowych" tym bardziej, że dla większości stanowią one poważny problem?

· Klienci systemu pomocy społecznej
Klientami urzędów pracy jest znacząca część podopiecznych systemu pomocy społecznej. Trafiają oni kierowani przez pracowników opieki (np. w poszukiwaniu zatrudnienia), albo w celu uzyskania zaświadczeń. Otrzymanie zatrudnienia przez bezrobotnego i podopiecznego systemu pomocy społecznej jest najlepszym sposobem likwidacji zapotrzebowania tej osoby na usługi pomocy społecznej. Postawmy zatem pytanie: czy można tak przebudować system informatyczny, aby klient pomocy społecznej i urzędu pracy np. nie musiał się dwukrotnie rejestrować, przedstawiać zaświadczeń, uzyskiwać oferty pracy, niezależnie, czy jest właśnie w ośrodku pomocy społecznej, czy powiatowym urzędzie pracy?

· Pracodawcy
Pracodawcom zależy na znalezieniu odpowiednich pracowników, tj. zarówno odpowiednio wykształconych, jak i posiadających doświadczenie, czyli takich, którzy są w stanie zastosować swoje umiejętności w praktyce. Obecnie pracodawcy zobowiązani są do zgłaszania wszystkich wolnych miejsc pracy do urzędów pracy. Nawet jeżeli traktują to, jako zło konieczne, to możliwość spełniania ustawowych powinności na odległość, byłaby dla nich istotnym ułatwieniem, e-government mógłby być więc "dostarczony" z systemem obsługi, jako rozszerzenie standardu. 
· Powiatowe urzędy pracy
Uwarunkowania obiektywne są takie, że powiatowe urzędy pracy są zaabsorbowane w związku z realizacją zadań pasywnych i wynikających 
z tego powodu obciążeń i procedur. Nawet jeżeli tak miałoby pozostać (że urzędy będą realizowały zadania pasywne), to istnieje realna szansa na zautomatyzowanie jak największej liczby tych procesów i zwolnienia zasobów dla form aktywnych. Cel jest tym realniejszy, że w otoczeniu instytucjonalnym systemy informatyczne są już mocno zaawansowane. Skoro urzędy będą nadal realizować zadania takie, jak:
1) prowadzenie rejestrów bezrobotnych, 
2) dysponowanie środkami Funduszu Pracy na świadczenia dla bezrobotnych (zasiłki, składki na ubezpieczenia), 
to korzystniej byłoby, aby koncentrowały się na pełnieniu roli:
3) pośrednika pomiędzy osobami poszukującymi pracy oraz pracodawcami poszukującymi pracowników,
4) instytucji ułatwiającej bezrobotnym znalezienie pracy (poprzez: szkolenia, kluby pracy, staże),
5) subsydiowania pracodawców, którzy tylko na takich warunkach są gotowi zaoferować pracę dla zarejestrowanych bezrobotnych lub osób poszukujących pracy. 

Przy spełnieniu powyżej wskazanej restrukturyzacji zasobów urzędy mogłyby satysfakcjonująco (dla klientów i siebie samych), jak najszybciej powodować, aby zarejestrowani bezrobotni otrzymali zatrudnienie, najlepiej takie, które gwarantowałoby, że podejmując pracę nie powrócą do bezrobocia. 

· Wojewódzkie urzędy pracy
Wojewódzkie urzędy pracy, zapewne tak jak dotychczas będą koncentrowały się na zadaniach, polegających na planowaniu polityki rynku pracy w skali województwa i świadczeniu wyspecjalizowanych usług. System informatyczny powinien więc dostarczać im informacji o rynku pracy, wspierać przygotowywanie zestawień statystycznych, dysponować środki, świadczyć usługi z zakresu eurodoradztwa, .... Jest to tym ważniejsze, że dzisiaj wojewódzkie urzędy pracy nie są włączone w sposób zadowalający do sieci informacji o rynku pracy, i trochę spontanicznie rozwiązują obsługę informatyczną.
· Ośrodki pomocy społecznej i powiatowe centra pomocy rodzinie Już wyżej wspomniano, że klienci pomocy społecznej trafiają również do urzędów pracy, przynajmniej po dodatkowe dokumenty, zaświadczenia. Nic nie stoi na przeszkodzie, aby ops i pcpr mogły wykorzystywać pewne zasoby (tutaj można wspomnieć chociażby o ofertach pracy) na zasadzie wspólnej z urzędami pracy. Możliwości technologiczne nie stanowią już większej przeszkody. 
Jeżeli sposób opisu osób, ofert, świadczeń, pracodawców i instytucji współpracujących ulegnie standaryzacji systemy informatyczne ops, pcpr i pup ulegną upodobnieniu, żeby nie stwierdzić, że "zleją" się w jeden wspólny. 

· Regionalne ośrodki pomocy społecznej, wydziały polityki społecznej 
Zarówno regionalne ośrodki pomocy społecznej, jak i wydziały polityki społecznej realizują zadania, które w części polegają na wypełnianiu zadań o charakterze koordynacyjnym. Pełnią nadzór, wsparcie w stosunku do innych jednostek na terenie województwa, ale także świadczą usługi, jako jedyne jednostki w województwie: kontrola legalności zatrudnienia, obsługa zatrudnienia cudzoziemców w Polsce. Z tego widać, że mają (i będą miały) duże zapotrzebowanie na informacje o charakterze statystycznym, ale także dostęp do niektórych zasobów (najlepiej jeżeli od razu) budowanych, jako ogólnokrajowe. Zauważmy, że informacje, o których mowa powinny pochodzić zarówno z systemu rynku pracy, jak i pomocy społecznej.

· Państwowy Fundusz Rehabilitacji Osób Niepełnosprawnych (PFRON) i Fundusz Gwarantowanych Świadczeń Pracowniczych (FGŚP) - inne instytucje rynku pracy
W tym miejscu zostanie zaledwie odnotowany fakt istnienia instytucji (takich, jak: PFRON, FGŚP, ale i innych), które dodatkowo wypełniają sferę instytucjonalnej obsługi zadań z zakresu rynku pracy i pomocy społecznej. Ważne jest jednak to, że te i inne instytucje powinny być włączone do jednolitego systemu informacyjnego, albo mieć możliwość korzystania 
z systemu obsługi rynku pracy, w stopniu zapewniającym integralność danych dotyczących osób i wybranych grup podmiotów. 

· Ministerstwo, instytucje centralne
Dzisiaj, jednym z zarzutów formułowanych pod adresem istniejącego systemu jest to, że zawiera on dane najpełniej satysfakcjonujące "Centralę" (np. ministerstwo). Trudno takiego zarzutu nie przyjąć, tym bardziej, że "Centrala" ma określone potrzeby wynikające z zadań planistycznych, ale i też z potrzeby formułowania ocen i przeprowadzania analiz doraźnych. W istocie system powinien łączyć różne aspekty: wymagania ustawowe, potrzeby "Centrali", zapotrzebowania na dane pozwalające rea-
lizować politykę rynku pracy na stopniu lokalnym i wojewódzkim, być na tyle elastycznym, aby odpowiedzi na "dowolne" pytania nie były absorbujące. 

· Samorządy: gminny, powiatowy, wojewódzki
Jakkolwiek powiatowy urząd pracy jest jednostką będącą w kompetencji samorządu powiatowego, to jednak inne są zadania i odniesienia do problematyki rynku pracy z poziomu pup, a inne z poziomu starosty. Podobna sytuacja będzie odpowiednio na poziomie gminy i województwa. Odnosząc się do tytułu rozdziału, samorządy tworzą otoczenie dalsze i tak powinny być zdefiniowane w systemie informatycznym. Zainteresowanie samorządów będzie "przesunięte" w stronę informacji ogólniejszych, zarządczych, podczas gdy urzędów pracy w stronę informacji szczegółowych, jednostkowych.

· Urzędy skarbowe, ZUS, urzędy statystyczne, banki
Grupa instytucji z otoczenia rynku pracy (a więc i systemu informatycznego) jest wyjątkowo liczna. Każda z nich jest zainteresowana inną porcją informacji, ale też każda z nich może innych informacji dostarczyć do systemu. 
Szczególną rolę dla systemu będą spełniały banki (dodajmy też pocztę) pełniące najczęściej ostatnie ogniwo wypłat zasiłków. System powinien umożliwiać realizację wypłat świadczeń beneficjentom za pośrednictwem systemu bankowego, ale w taki sposób, aby minimalizować koszty i pozwalać aktywnie zarządzać całością środków. Pewną ilustracja jest rysunek 5 w dalszej części artykułu.
· Producenci oprogramowania wykorzystywanego w jednostkach systemu urzędów pracy i systemu pomocy społecznej
Zamknijmy charakterystykę otoczenia systemu wskazaniem na dostawców oprogramowania. Jest to "element" otoczenia wyjątkowo istotny, jako że dostawcy gwarantują świadczenie usług rynku pracy poprzez dostawę oprogramowania, ale także traktują tę sferę (jest to naturalne), jako źródło przychodów. Mają więc swoje interesy biznesowe, które mogą być rozłączne z interesami instytucji rynku pracy, w obszarze takich kwestii, jak np.: konkurencyjność oprogramowania, koszt usług serwisowych, aktualizacja oprogramowania, rozbudowa i innowacje.


2. Stan aktualny

Informatyzacja systemu urzędów pracy (oraz systemu opieki społecznej) była celem, prowadzonego w latach 1992-1999, projektu ALSO (Automation of the Labour and Social Welfare Organisation) oraz prac wykonywanych wokół systemów informatycznych PULS (i POMOST), prowadzonych dalej (i obecnie) po ogłoszeniu zakończenia projektu ALSO. Po 3. latach po ogłoszeniu zakończenia projektu ALSO, jawi się on jako: 
1. Projekt, którego zakres (stanowiony przez zbiór wymagań funkcjonalnych) oraz ramy czasowe były ściśle uzależnione od kontraktu na finansowanie przedsięwzięcia, zawartego z Bankiem Światowym (skończyło się finansowanie ® ogłoszono koniec przedsięwzięcia, mimo że przypisany mu zakres nie był zaimplementowany w pełnym stopniu, a prace wdrożeniowe tego, co już udało się wytworzyć, były dopiero w toku). 
2. Projekt, w ramach którego zespół finansowany z jednego budżetu i znajdujący się pod wspólnym kierownictwem, zajmował się wytworzeniem 3. niezależnych systemów informatycznych (dla systemu urzędów pracy = PULS, dla systemu pomocy społecznej = POMOST oraz dla centrali MPiPS).
3. Projekt, w wyniku którego powstały systemy informatyczne wspomagające prace prowadzone w sup oraz sps są wykorzystywane, jako od siebie niezależne.
· PULS - System Informatyczny (SI) systemu urzędów pracy
Wymagania na system PULS zostały przygotowane w roku 1995. Wskazano wówczas na konieczność wytworzenia, w docelowej wersji 2.0 systemu PULS ponad 20 aplikacji funkcjonalnych. Spośród nich do dnia dzisiejszego powstały i są użytkowane (w różnym stopniu) wykorzystywanych przez urzędy pracy i ich filie (Administrator, Finanse, Formalna Obsługa Osób, Pośrednictwo Pracy, Prace Okresowe i Staże, Statystyka, Szkolenia i Poradnictwo Zawodowe, Świadczenia Finansowe), 3 dalsze zostały z końcem 2002 r. wdrożone (Kadry, Płace, Wskaźniki Efektywności).
Poziom faktycznego wykorzystania aplikacji systemu PULS jest bardzo różnorodny i nie zawsze możliwy do oszacowania. Na fakt ten ma wpływ kilka czynników. System PULS jest wybiórczo wykorzystywany w wojewódzkich urzędach pracy, choć wydaje się, że mógłby być użytkowany przynajmniej w zakresie aplikacji FK (Finanse), a w najbliższej przyszłości również aplikacji KD (Kadry) oraz PL (Płace). 
System Informatyczny PULS jest systemem zintegrowanym przez dane, przy czym integracja ta dotyczy jedynie poszczególnych instalacji systemu; jest zintegrowany w ramach powiatowych urzędów pracy (i niekiedy) ich filii, w których jest wykorzystywany. Oznacza to, że poszczególne aplikacje SI PULS korzystają z jednej, współdzielonej bazy danych, a zatem dane wprowadzone do systemu za pomocą jednej aplikacji mogą być odczytywane, przetwarzane i modyfikowane przez użytkowników innych aplikacji. Poszczególne instalacje SI PULS nie zostały ze sobą zintegrowane. PULS został utworzony w najbardziej popularnej, w pierwszej połowie lat dziewięćdziesiątych XX wieku, chociaż obecnie już rzadko polecanej, dwuwarstwowej architekturze klient-serwer, z tzw. "grubym klientem". Architektura ta, mimo że w początku lat 90. XX w. była uważana za rewolucyjną, ma wady, które dzisiejsze techniki informatyczne są w stanie wyeliminować.
Oprócz systemu PULS w wielu powiatowych urzędach pracy, wykorzystywane są jeszcze inne systemy informatyczne, w zastępstwie PULS-u lub jako jego uzupełnienie (np. BEZROB, RUBIKOM). Do tego dodajmy też aplikacje napisane np. w MS Access przeznaczone do przygotowania zestawień statystycznych. W wup-ach wykorzystywane są aplikacje umożliwiające weryfikowanie poprawności plików DBF, zawierających statystyki MGPiPS, które wojewódzkie urzędy pracy otrzymują od powiatowych urzędów pracy i przekazują do wojewódzkich urzędów statystycznych. 

3. Problemy

Analiza zastosowania SI PULS ujawnia szereg problemów. Niektóre z nich zostały w dalszej części zasygnalizowane. Nie wyczerpuje to pełnej listy problemów.

· Problemy z bieżącym śledzeniem wydatków i określeniem zapotrzebowania na fundusze z Funduszu Pracy (FP)
Dysponent Funduszu Pracy, przekazujący środki na realizację zadań urzędów pracy musi mieć wystarczające, bieżące informacje o rzeczywistym zapotrzebowaniu poszczególnych jednostek. Z drugiej strony, dysponent FP musi mieć pewność, że środki, które przekazuje są prawidłowo wykorzystywane. Przydział środków finansowych na urzędy pracy realizowany jest zgodnie z algorytmem ogłoszonym we właściwym rozporządzeniu. Gdyby informacja o aktualnym stanie zapotrzebowania i wykorzystania funduszy przez urzędy pracy była dostępna dysponentowi FP na bieżąco, to sterowanie wykorzystaniem pieniędzy mogłoby być realizowane bardziej racjonalne. 

· Problemy z monitorowaniem bezrobotnych
Istnieje potencjalne zagrożenie dokonania rejestracji bezrobotnego w więcej niż jednym urzędzie pracy (złożenie fałszywego oświadczenia na karcie rejestracyjnej). Pracownik pup dokonujący rejestracji, może zadzwonić do innego pup i zapytać, czy dana osoba nie jest tam zarejestrowana. Nie ma jednak obecnie technicznej możliwości, aby system PULS sam poinformował, że rejestrowana osoba ma swój wpis również w innej instalacji tego systemu. 
Rejestrowane dane klientów urzędów pracy są obecnie weryfikowane pod względem aktualności i prawdziwości poprzez porównanie ich przez pracownika pup z dokumentami źródłowymi przedłożonymi przez klienta. Nie ma możliwości, aby system dostarczył informacji (np. po weryfikacji z ZUS) czy dokumenty zawierają prawdziwe dane.

· Przestarzałe narzędzia informatyczne
System PULS w całości został wykonany w technologii Progress w wersji 7.3c (baza danych Progress RDBMS i okienkowa aplikacja użytkownika końcowego Progress 4GL.). Jest to technologia, która od przeszło dwóch lat nie jest już oferowana przez firmę Progress - firma nie rozprowadza tego oprogramowania i nie prowadzi szkoleń. Wersja Progress 7.x była pierwszą wersją tego systemu, umożliwiającą programowanie aplikacji z graficznym interfejsem użytkownika, pod nadzorem systemu operacyjnego Windows. 
Narzędzia te były przystosowane do pisania aplikacji w architekturze klient-serwer z tzw. "grubym klientem" metodami strukturalnymi. 
Język Progress 4GL jest własnym rozwiązaniem firmy Progress, mającym zastosowanie jedynie komercyjne. Istnieje małe prawdopodobieństwo, aby szkoły, w których uczy się programowania wykorzystywały ten język w procesie kształcenia. Rynek programistów w naszym kraju charakteryzuje się raczej niewielką podażą specjalistów znających to rozwiązanie. 

· Przestarzała architektura systemu
Architektura klient-serwer (zastosowana dla SI PULS) z "grubym klientem" ma jeszcze inne wady, które mogły być niedostrzegane wówczas, gdy rozpoczynano prace nad systemem PULS (1995 rok). Ogólnie ujmując jest przestarzała.

· Duże wymagania w stosunku do przepustowości sieci lokalnych
Architektura klient-serwer z "grubym klientem", zastosowana w systemie PULS powoduje, że wszelkie dane składowane na serwerze bazy danych, niezbędne do wykonania na nich obliczeń (np. zestawień statystycznych MGPiPS) muszą zostać przesłane do aplikacji działającej na stacji roboczej użytkownika końcowego aplikacji. Skutkuje to masowym przesyłaniem danych w sieci LAN, co wydłuża czas oczekiwania na odpowiedź systemu wszystkim pozostałym użytkownikom, również tym, którzy nie korzystają w danej chwili z funkcji charakteryzujących się dużym zapotrzebowaniem na dane. 

· Uzależnienie urzędów pracy od jednego dostawcy usług IT
Z realizacją całości systemu tylko przez jednego wykonawcę wiążą się wszystkie te zagadnienia, które związane są z brakiem konkurencji, aczkolwiek na problem można patrzeć też z innej strony, mówiąc, że z takiego układu płyną również znaczne korzyści. Stronie zamawiającej o wiele łatwiej jest komunikować się (przekazywać wymagania i akceptować ich realizację), jeżeli ma do czynienia z mniejszą (w szczególności z jednym) liczbą usługodawców. 


4. Technologiczne i architektoniczne możliwości rozwiązania problemów

Rozważając kierunek zmian w rozwoju systemu informatycznego dla urzędów pracy warto uwzględnić wskazane powyżej problemy i wnioski wynikające z analizy stanu aktualnego. Niektóre z nich daleko wykraczają poza zwykłą modernizację systemu i postulują budowę jakościowo nowego rozwiązania. 

· Uniezależnienie od jednego dostawcy oprogramowania końcowego (systemu)
Chodzi o realną możliwość rezygnacji z usług jednego dostawcy oprogramowania i skorzystania z oferty innego. Uniezależnienie może oznaczać możliwość przejęcia dalszego utrzymania i rozwoju oprogramowania przez nowego dostawcę, lub w ogóle możliwość wymiany (migrację danych) fragmentu (lub całego) oprogramowania opracowanego przez dotychczasowego dostawcę na nowy opracowany przez konkurencyjną firmę bez zaburzania ciągłości wykorzystania systemu. 
Uniezależnienie od dostawcy wzmacnia argumenty negocjacji odbiorcy, wpływa na podniesienie jakości usług oferowanych przez dostawców oraz obniża ryzyko utraty wsparcia dla rozwiązania z powodu kłopotów firmy - dostawcy. 

· Uniezależnienie od jednego dostawcy technologii
Warto zapewnić sobie możliwość rezygnacji z technologii wykorzystanej do konstrukcji systemu, dostarczanej przez jednego producenta i zastąpienie jej konkurencyjnym rozwiązaniem. Przykład: możliwość wymiany serwera bazy danych lub serwera aplikacji. 
Uniezależnienie od dostawcy technologii obniża ryzyko braku możliwości dalszego utrzymania i rozwoju systemu z powodu upadku producenta oprogramowania lub zaprzestania utrzymywania przez niego konkretnego produktu. Ponadto daje możliwość wybrania rozwiązania najkorzystniejszego ze względu na koszty. 

· Uniezależnienie od konkretnej wersji oprogramowania systemowego i technologii
Uniezależnienie pozwala uniknąć sytuacji, w której niemożliwy jest dalszy rozwój oprogramowania z powodu zaprzestania wspierania konkretnej wersji produktu wymaganego przez aplikację. Nie dojdzie do sytuacji, w której przy zakupie nowego sprzętu trzeba zrezygnować z nowszej, aktualnej wersji systemu operacyjnego na rzecz starszej wymaganej przez oprogramowanie. 

· Minimalizacja kosztów budowy i utrzymania infrastruktury technicznej
Najlepiej by początkowe wymagania stawiane sprzętowi i oprogramowaniu systemowemu były jak najmniejsze, co wpływa na obniżenie kosztów uruchomienia systemu. Ważne jest także, by wymagania stawiane sprzętowi oraz systemom operacyjnym przez powstające nowe wersje oprogramowania nie wymuszały konieczności zmian tych pierwszych. 

· Minimalizacja kosztów administrowania systemem
Minimalizacja kosztów administrowania systemem dotyczy między innymi takich operacji, jak podłączanie do systemu nowych użytkowników (w tym przygotowywania nowych stacji roboczych), usuwania awarii, czy na przykład konfiguracji serwera bazy danych pod kątem jego efektywnego funkcjonowania. 
Najlepiej, by liczba sytuacji wymagających interwencji administratora była ograniczona do minimum, a interwencje nie pociągały za sobą wysokich kosztów (np. mogły być wykonywane zdalnie). Korzystne jest także, by system był skonstruowany w taki sposób, żeby liczba osób pełniących rolę administratora mogła być mała.

· Minimalizacja kosztów rozwoju systemu
Tutaj koszty rozwoju rozumiane są, jako koszty wprowadzania zmian do systemu. Koszty rozwoju systemu są pochodną wybranej architektury, technologii oraz sposobu napisania oprogramowania, które składa się na rozwiązanie końcowe. 

· Minimalizacja kosztów i czasu wprowadzania nowych wersji systemu
Chodzi o zapewnienie, by wprowadzenie zmian i dystrybucja nowych wersji oprogramowania nie wymagały dużego nakładu pracy, czasu i nie prowadziły do dużego przedsięwzięcia organizacyjnego, a także by liczba uaktualnień wykonywanych przez administratorów była jak najmniejsza. 

· Minimalizacja czasu wprowadzania zmian do systemu
Chodzi o czas, który upływa od momentu zgłoszenia potrzeby zmiany do momentu dostarczenia użytkownikowi oprogramowania implementującego ją. Krótki czas wprowadzania zmian do systemu pozwoli na utrzymanie aktualności systemu, tj. nadążanie systemu za rosnącymi wymaganiami użytkowników oraz za zmianami prawa, w ramach, którego działa. 

· Możliwość korzystania z logiki biznesowej systemu przez aplikacje trzecie
Jest to możliwość skorzystania z usług zaimplementowanych w systemie przez inne, zewnętrze systemy. Cecha upraszcza (a tym samym obniża koszt) lub w ogóle umożliwia integrację posiadanych aplikacji.

· Skalowalność systemu
Skalowalność jest rozumiana jako podatność systemu na zmiany np. sprzętowe. Uzyskuje się to m.in. "dodaniem" procesorów, pamięci, itp. 
i wówczas należy mieć pewność, że wraz ze wzrostem liczby użytkowników oraz liczby danych, system będzie dalej efektywnie działał. 

· Niezawodność systemu
Niezawodność rozumiana jest jako ograniczenie czasu przestojów z powodu awarii systemu. 
Na niezawodność systemu ma wpływ jakość samego systemu (błędy 
w oprogramowaniu), jak i dojrzałość technologii wykorzystanych do jego budowy. 

4.1. Rozwiązanie istniejące
Systemy SI PULS i POMOST opracowane w architekturze klient-serwer nie pozwolą na osiągnięcie wszystkich z wymienionych wyżej celów. Utrzymanie istniejącego modelu klient-serwer należy traktować w kategorii przedłużenia życia istniejącego systemu dla zapewnienia płynnego przejścia użytkowników do nowego rozwiązania oraz dla pozyskania doświadczeń i wniosków (również przez użytkowników końcowych), które posłużą do opracowania nowego rozwiązania. 
Z technicznego punktu widzenia system (PULS ale i POMOST) można rozwijać dalej. Można dodawać nową funkcjonalność, można nawet integrować poszczególne systemy działające w różnych jednostkach organizacyjnych pomocy społecznej (JOPS) i rynku pracy (RP), żeby możliwa była wymiana danych pomiędzy nimi. Rosnące i coraz bardziej zaawansowane wymagania użytkowników będą zwiększały ruch w sieci, co znowu odbije się na wydajności pracy. 
Dalszy rozwój systemu przy zachowaniu obecnej architektury nie ma sensu z powodów ekonomicznych. Stale rosnące wydatki nie będą przybliżały do określonych celów. Zatem w grę wchodzi stworzenie nowego systemu, który powinien powstać w terminie takim, aby utrzymać wydatki poniesione na utrzymanie istniejącego rozwiązania na minimalnym poziomie. 

4.2. Rozwiązanie docelowe
Za docelową architekturę, do której należy dążyć tworząc nowe rozwiązanie jest architektura wielowarstwowa, czyli taka, w której zostały zidentyfikowane i rozdzielone co najmniej trzy warstwy logiczne: warstwa interfejsu użytkownika, logiki biznesowej oraz warstwa przechowywania danych. By osiągnąć wszystkie wymienione wcześniej cele, tworząc nowe rozwiązanie, należy także wziąć pod uwagę następujące posunięcia: 

· Zastosowanie standardów obowiązujących na rynku
Zarówno w zakresie języków oprogramowania (np. Java), wymiany danych (np. XML), komunikacji (np. COM, CORBA, EJB), prezentacji (np. HTML, XSL), jak i środowisk - serwerów aplikacji i serwerów baz danych. Zastosowanie standardów pozwoli uniezależnić się od jednego dostawcy oprogramowania. Zastosowanie standardów pozwoli także uniezależnić się od jednego dostawcy technologii, ponieważ standardy wspierane są przez wielu producentów. 

· Podzielenie warstwy logiki biznesowej na komponenty 
Wprowadzenie komponentów biznesowych pozwoli uniezależnić się od jednego dostawcy oprogramowania - komponent jednego dostawcy będzie można zastąpić komponentem innego. Co więcej, w ten sposób będzie można złożyć rozwiązanie z komponentów opracowanych przez różne firmy, z których każda specjalizuje się w danej dziedzinie problemu (np. w finansach i księgowości) uzyskując w ten sposób wsparcie użytkownika w większym zakresie wymagań.
Zastosowanie komponentów skróci czas wprowadzania zmian do systemu, ponieważ każda zmiana dotyczyć będzie wydzielonego, mniejszego niż cały system komponentu, którym zajmować się będzie firma skoncentrowana na jego rozwijaniu i specjalizująca się w obsługiwanym przez niego obszarze zastosowań. 

· Zapewnienie by interfejs użytkownika był uruchamiany w przeglądarce internetowej
Inaczej mówiąc zapewnić, by klient logiki biznesowej programu był "najcieńszym" z możliwych. Rozwiązanie to uniezależni odbiorcę od konkretnej wersji oprogramowania systemowego, wpłynie na obniżenie kosztu stacji roboczej, przedłużenie czasu jej życia, obniży koszty instalacji stacji roboczych (przeglądarka wchodzi w skład oprogramowania standardowo instalowanego na komputerze), obniży koszt administrowania stacjami roboczymi oraz obniży koszt wprowadzania nowych wersji systemu. 
Dodatkowo, zastosowanie przeglądarki (i rozdzielenia logiki programu) zagwarantuje możliwość efektywnego korzystania z systemu
w sposób zdalny bez konieczności spełnienia wygórowanych wymagań w stosunku do przepustowości łączy. Proponowaną architekturę prezentuje rysunek 1. 
Wadą opisanej propozycji może być większy koszt jej opracowania, wynikający z konieczności precyzyjnej specyfikacji poszczególnych składowych systemu. Z drugiej strony, wyższy koszt wytworzenia będzie zrekompensowany niższymi kosztami integracji systemu z innymi aplikacjami, niższymi kosztami wprowadzania zmian, przedłużeniem czasu życia systemu oraz niższym całkowitym kosztem posiadania systemu. 

4.3. Sposoby osiągnięcia rozwiązania docelowego
Możliwe są dwa sposoby osiągnięcia architektury docelowej: migracja istniejącego rozwiązania do architektury wielowarstwowej oraz konstrukcja nowego rozwiązania. 

Rysunek 1. Proponowana architektura systemu

Migracja istniejącego rozwiązania nie pozwoli na osiągnięcie wszystkich wymienionych powyżej celów. Nie da się w ten sposób uniezależnić od jednego dostawcy technologii ponieważ rozwiązania oferowane przez Progress Software (a te musiały być zastosowane) są rozwiązaniami własnymi, niestandardowymi. Tym samym pod znakiem zapytania stoi uniezależnienie od jednego dostawcy oprogramowania końcowego. Zdecydowanie lepszym rozwiązaniem jest konstrukcja oprogramowania od początku w oparciu o doświadczenia z wykorzystania istniejącego systemu.
Rozwiązanie konstruowane od nowa oznacza opracowanie oprogramowania od początku w oparciu o doświadczenia pozyskane z wykorzystania istniejącego systemu. Pierwszym założeniem jest skorzystanie z wiedzy i doświadczeń zdobytych w czasie użytkowania systemów PULS i POMOST, a nie z istniejącego kodu. Drugim, standaryzacja rozwiązania w oparciu o architekturę wielowarstwową i technologię wspierającą konstrukcję oprogramowania na bazie komponentów, które z kolei korzystają 
z powszechnie akceptowanych standardów przemysłowych. Nie jest to standaryzacja na bazie jednej aplikacji, ani jednego dostawcy. 

Rysunek 2. Przykładowe rozlokowanie w kraju centrów przetwarzania

Nowe oprogramowanie opracowane w architekturze wielowarstwowej przy zapewnieniu zgodności z ustalonymi standardami obowiązującymi na rynku, warstwą logiki biznesowej podzieloną na komponenty biznesowe oraz z interfejsem użytkownika uruchamianym w przeglądarce. 
Rozwiązanie wykorzystujące serwery aplikacji, na których ulokowana jest logika biznesowa. Pozwalające na rozproszenie logiki bez utraty możliwości współpracy pomiędzy fragmentami systemu, zwiększające możliwości skalowalności systemu, równoważenia obciążenia oraz nie nakładające ograniczeń na lokalizację poszczególnych elementów architektury. 
Zastosowane architektura i technologia pozwalają utworzyć centra przetwarzania systemu. Centra byłyby rozmieszczone w różnych miejscach kraju i świadczyłyby usługi użytkownikom końcowym. Użytkownik korzystając z nowego systemu rzeczywiście łączyłby się z centrum obsługującym go. W centrach znajdowałyby się serwery aplikacji (logika biznesowa) i baz danych (dane). Centrum odpowiadałoby za bezawaryjne i efektywne działanie systemu. W zakresie obowiązków pracowników centrów znajdowałaby się także instalacje nowych wersji oprogramowania. Istnienie centrów nie musi oznaczać współdzielenia danych - może być tylko współdzieleniem infrastruktury przy zachowaniu rozłączności danych poszczególnych jednostek. Należy podkreślić, że architektura i technologia pozwala odsunąć konieczność podjęcia decyzji w tym zakresie nawet po etap wdrożenia systemu. Koncepcja centrów przetwarzania danych pozwala obniżyć koszt budowy i utrzymania infrastruktury oraz koszt administracji systemem, zdejmując te obowiązki z poszczególnych jednostek organizacyjnych pomocy społecznej i rynku pracy. Zadaniem jednostek pozostanie zapewnienie użytkownikom stacji roboczych o niewygórowanych parametrach, z zainstalowaną przeglądarką oraz łączy gwarantujących komunikację z centrum. Rozwiązanie jest szczególnie korzystne dla małych jednostek. 
Centra mogłyby być utworzone i zarządzane przez MGPiPS, ale również mogłyby to być centra firm trzecich. W tym drugim przypadku można wybierać model współpracy pomiędzy kolokacją (umieszczeniem własnej infrastruktury w centrum), hostingiem (używanie własnego oprogramowania korzystającego z infrastruktury firmy trzeciej), a modelem ASP (wynajmowanie za pośrednictwem sieci oprogramowania, które korzysta z infrastruktury firmy trzeciej i jest jej własnością). Znowu, decyzję o wyborze modelu obsługi centrów można podjąć dopiero na etapie wdrożenia systemu. Warto podkreślić rosnące zainteresowanie rynku tego typu usługami poparte optymistycznymi prognozami jego rozwoju oraz coraz większą liczbą powstających firm świadczących takie usługi. 
Lokalizacja centrów nie musi pokrywać się z podziałem administracyjnym kraju. Jako kryterium lokalizacji można rozważyć np. równoważenie liczby mieszkańców obsługiwanych przez centrum (równoważenie obciążenia systemu) lub wykorzystanie istniejącej infrastruktury sieci (minimalizacja nakładów na infrastrukturę). Liczba centrów powinna być na tyle duża by użytkownicy systemu obsługiwani byli sprawnie i na tyle mała by nakłady poniesione na ich utworzenie (sprzęt, oprogramowanie systemowe, sieć, infrastruktura techniczna) oraz ponoszone na ich utrzymanie (m.in. administrowanie systemami zlokalizowanymi w centrach) były jak najmniejsze. 
Druga koncepcja, którą warto zastosować przy konstruowaniu nowego rozwiązania to komponenty biznesowe, rozumiane jako dobrze zdefiniowane fragmenty systemu, świadczące konkretne usługi z dziedziny problemu jakiej dotyczą, przez dobrze zdefiniowane interfejsy. Przykładami komponentów biznesowych, elementów nowego systemu mogłyby być: formalna obsługa osób, pośrednictwo pracy. Wspólną cechą wymienionych komponentów jest to, że każdy z nich świadczy usługi ze znanej i dobrze opisanej dziedziny problemu, często musi spełniać konkretne wymagania opisane prawem. 
Nowy system powinien być konstruowany równocześnie przy utrzymaniu funkcjonowania istniejącego rozwiązania. Dopiero po zakończeniu prac, potwierdzeniu jakości i przeniesieniu danych użytkownicy rozpoczną z niego korzystanie. Przejście pomiędzy systemami nie będzie płynne, może stwarzać problemy użytkownikom i będzie wymagać odpowiedniego wsparcia. 

Zalety
· osiągnięcie celów, w szczególności szerokie możliwości integracji z innymi aplikacjami na bazie używanych standardów,
· porzucenie balastu starego rozwiązania (np. kodu, konkretnych rozwiązań), możliwość skonstruowania zupełnie nowego rozwiązania tylko w oparciu o doświadczenia i wnioski,
· możliwość wyboru dostawców poszczególnych składowych (komponentów) systemu,
· możliwość wyboru modelu utrzymania systemu, w szczególności skorzystania (np. w drodze przetargu) z ofert specjalistycznych firm,
· przerzucenie, części kosztów konstrukcji rozwiązania, na firmy dostawców poszczególnych komponentów biznesowych,
· skrócenie czasu opracowywania nowego rozwiązania,
· uproszczenie i przyspieszenie procesu homologacji (weryfikacji),
· częściowe wykorzystanie istniejącej infrastruktury (przeznaczenie komputerów na stacje robocze o niewygórowanych parametrach).

Wady i zagrożenia
· szokowe przejście użytkowników do używania nowego systemu,
· problem migracji danych,
· ryzyko związane z realizacją przedsięwzięcia od zera,
· wymagania dotyczące zespołu projektowego - złożona architektura, konieczność definicji standardów wymaga dużej wiedzy,
· konieczność współpracy z wieloma dostawcami. 


5. System informatyczny przyszłości - logika przestrzenna

Na system informatyczny nieodległej przyszłości warto spojrzeć jeszcze w inny sposób. Nazwano to "logiką przestrzenną", ale tak naprawdę chodzi o zrozumienie filozofii tego systemu. Na kolejnych rysunkach pokazano jak ten system trzeba rozumieć, jeżeli spojrzeć na pojedynczą instalację, jak "widzieć" go w układzie przestrzennym, a jak w układzie funkcjonalnym.
Na rys. 3. pokazano strukturę systemu w lokalnej instalacji. Jest on oparty na magazynie danych zarządzanych w sposób niezawodny i bezpieczny, a poszczególne aplikacje korzystając z magazynu realizują funkcje biznesowe i pomocnicze.
Aplikacje, o których mowa powinny być podzielone jeszcze w jeden sposób (wyżej to zostało nadmienione). Aplikacje biznesowe, będą zamawiane i ściśle monitorowane z jednego ośrodka (np. tak jak teraz SI PULS), aplikacje pomocnicze mogą podlegać homologacji, albo będą zamawiane w sposób rozproszony, ale tak, aby utrzymać spoistość danych na wejściu/wyjściu.
Ten sam system będzie posiadał zasoby rozlokowane w sposób rozproszony, ale taki, aby dostęp nie powodował utrudnień i nie skutkował blokadą pracy. Na rysunku 4. pokazano, że zasoby informacyjne będą umieszczone na 4. poziomach. Poziom gminy to zasoby dotyczące podstawowej obsługi klienta; poziom powiatowy to już elementy hurtowni danych (lub zasoby pełne dla wszystkich jednostek z terenu powiatu, a więc i gmin - jest to wariant alternatywny wobec poprzedniego); poziom województwa to hurtownie danych, pozwalające na realizację zadań analitycznych i planistycznych. W zasadzie, wobec przyjętej technologii internetowej, nie będzie potrzebny mechanizm replikowania baz powiatowych, a klienci będą obsługiwani na poziomie województwa poprzez bezpośredni dostęp do ich macierzystej bazy; poziom centralny to pełna hurtownia danych i te zasoby, które powinny być dostępne wyłącznie z poziomu województwa.

Rysunek 3. Struktura systemu w lokalnej instalacji

Rysunek 4. Rozlokowanie zasobów wg kompetencji organów

Rysunek 5. pokazuje logikę systemu w układzie funkcjonalnym. Wyróżniono cztery filary funkcjonalne: 
· pierwszy zawiera dotychczasowy zakres funkcjonalny SI PULS, chociaż nie można wykluczyć, że ulegnie on pewnym zmianom,
· drugi odpowiada za aktywne zarządzanie finansami "przepływającymi" przez system do ostatecznego beneficjenta,
· kolejny skupia funkcje e-governmentu (załatwianie spraw urzędowych przy okazji wizyty w urzędzie),
· ostatni to obszar edukacyjny wsparty na (m.in.) distance lerning'u.

Rysunek 5. Obszary funkcjonalne systemu przyszłości

6. Sposób rozwiązania problemów

Rozpoczynanie prac nad nowym i zintegrowanym systemem informatycznym, powinno być poprzedzone odpowiednimi przygotowaniami. Działania takie powinny prowadzić do eliminacji wcześniej opisanych problemów, w kolejności:
· organizacyjnych,
· dotyczących wymagań na system,
· związanych z ograniczeniami aktualnie przyjętych rozwiązań technologiczno-architektonicznych.
Celem pierwszoplanowym powinna być poprawa wykorzystania aktualnego stanu posiadania. W drugiej kolejności, korzystając z doświadczeń uzyskanych podczas realizacji działań naprawczych, należy przystąpić do prac związanych z powstaniem nowego systemu informatycznego. 
Opisane podejście jest konsekwencją stwierdzenia, że wykorzystywane aktualnie systemy informatyczne, których celem jest wspieranie funkcjonowania jednostek systemu urzędów pracy i systemu pomocy społecznej, mogą swoje zadania póki co realizować. Systemy działają stabilnie, wspierają pracę użytkowników w zakresie zaimplementowanych funkcji, zakres zrealizowanych wymagań jest na tyle duży, że nie można systemom zarzucić braku przydatności. Natychmiastowe porzucenie istniejących systemów byłoby uzasadnione, gdyby te nie działały tak jak powinny w zakresie funkcji, które miały realizować (powód merytoryczny), albo gdyby nie mogły być używane z powodów jakościowych (błędy uniemożliwiające pracę, częste awarie oprogramowania, niemożliwy do zaakceptowania czas reakcji systemu na akcje użytkownika). 
· Określenie aktualnego przebiegu procesów realizowanych w jednostkach systemu urzędów pracy i systemu pomocy społecznej wykorzystujących SI PULS i POMOST
Istotne powinno być uzyskanie informacji o tym, w jaki sposób realizowane są obecnie wszystkie procesy w poszczególnych jednostkach systemu urzędów pracy i systemu pomocy społecznej. W jednych ośrodkach prace wykonywane są bardziej efektywnie niż w innych, w innych całe dnie przeznacza się na robienie czegoś, z czego gdzie indziej w ogóle zrezygnowano. Wysoce wskazanym jest, aby wszyscy klienci systemów sup i sps mogli spodziewać się tego samego poziomu usług, bez względu na miejsce występowania. Wysoce wskazanym jest również, aby wszystkie ośrodki pracowały możliwie najefektywniej (zgodnie z bieżącym ich stanem wiedzy). Zapewnić to może standaryzacja (unifikacja) i sprawne propagowanie wszelkich nowości organizacyjnych. Standaryzacja pozwoli też na zmniejszenie wymagań funkcjonalnych na systemy informatyczne. 
Opisy procesów powinny dotyczyć tylko tych ośrodków, o których wiadomo, że korzystają z oprogramowania PULS i POMOST. Spośród nich należałoby wytypować reprezentatywne jednostki, najlepiej z różnych regionów kraju. 
Opisane procesy będą mogły posłużyć kilku celom: 
· udostępnieniu do wiadomości pozostałych jednostek i dzięki temu uzyskaniu informacji zwrotnych, wykazujących, że inni mają odmienne pomysły (pracują jeszcze efektywniej),
· samodzielnemu przeorganizowaniu pracy przez pozostałe jednostki (posiadające takie możliwości, tzn. posiadające systemy PULS lub POMOST), które zauważą, że marnują czas lub zasoby,
· wykryciu wąskich gardeł systemów urzędów pracy i systemów pomocy społecznej (zidentyfikowaniu akcji najbardziej czaso- i kapitałochłonnych), stanowiących wskazanie, od których miejsc powinno się rozpocząć optymalizację,
· rozpoznaniu faktycznie istotnych funkcji systemu informatycznego, a jednocześnie wykryciu tych funkcji, które nie mają w ogóle zastosowania,
· rozpoczęciu optymalizacji - tj. przeprojektowania istniejących procesów w taki sposób, aby ich koszt był niższy od procesów obecnie realizowanych.

Należy podkreślić, iż opisane w niniejszym rozdziale działania mogą stanowić krok w kierunku uzyskania przez systemy urzędów pracy i systemy pomocy społecznej certyfikatów jakości zgodnych z normami ISO 9000:2000. 

· Zunifikowanie i zoptymalizowanie procesów systemu urzędów pracy i systemu pomocy społecznej, z wykorzystaniem funkcjonalności SI PULS i POMOST 
Należy doprowadzić do przejrzenia aktualnych procesów, ich zunifikowania i ewentualnie przeorganizowania, z uwzględnieniem funkcjonalności oferowanych przez bieżące wersje SI PULS i POMOST. Prace powinny polegać na systematycznym przejrzeniu wszystkich procesów (krok po kroku) i odpowiedzi na pytania: 
· Który z wariantów jest tańszy i łatwiejszy do zrealizowania? 
· Czy dany krok jest rzeczywiście niezbędny, a jeśli tak, to dlaczego się tak wydaje?
· Czy danego kroku, wykonywanego ze wsparciem systemu informatycznego nie można realizować bardziej efektywnie (np. zrezygnować z wprowadzania pewnych danych, wprowadzić standardowe ścieżki wprowadzania danych)?
· Czy pewnych kroków nie należałoby połączyć tak, aby mogły być realizowane przez jedną osobę, na jednym stanowisku pracy?
· Czy danego kroku realizowanego dotychczas manualnie nie dałoby się realizować korzystając z funkcjonalności posiadanych systemów PULS i POMOST?
· Czy raz manualnie wprowadzona informacja nie powinna pojawiać się automatycznie w innych wymaganych miejscach?

· Doprowadzenie do wdrożenia procesów systemu urzędów pracy i systemu pomocy społecznej wspieranych przez SI PULS i POMOST w ośrodkach realizujących zadania bez tych rozwiązań
O zadaniu tym należy myśleć w kategoriach marketingowych. Wszystkim tym, którzy jak dotychczas nie zdecydowali się na wdrożenie systemów PULS i POMOST, należy pokazać, że: 
· posiada się wiedzę na temat zunifikowanych procesów sup i sps, wspomaganych przez system PULS i POMOST,
· prowadzi się ciągłe prace nad optymalizacją tych procesów,
· nie prowadzi się żadnych prac związanych z rozpoznaniem i optymalizacją procesów zachodzących w jednostkach nie wykorzystujących promowanych systemów informatycznych,
· używanie systemu ułatwia wykonywanie codziennych obowiązków.

Sprawnie przeprowadzone akcje promujące wspólnie wypracowane rozwiązania, poparte dowodami (jest opis procesów wraz z ich kosztami, zmniejszającymi się dzięki optymalizacji; jest portal wsparcia systemu urzędów pracy i systemu pomocy społecznej, dzięki któremu uczestnicy obu systemów mają faktyczne możliwości wpływania na rzeczywistość, mogą uzyskać szybkie wsparcie, porady lub też przedyskutować pewne kwestie z pracownikami innych jednostek) powinny spowodować, że wszyscy pracujący w inny sposób sami poczują potrzebę włączenia się w działania promowane (a nie narzucane) przez MGPiPS.


* * *
Stworzenie systemu, który w pełni wykorzystywałby możliwości techniczne i technologiczne będzie podlegało szeregowi ograniczeń. Jedne będą miały charakter subiektywny (brak zrozumienia, niechęć) inne obiektywny (brak środków, nierozpoznane problemy). Wynik będzie zapewne wypadkową kilku składowych, ale trud warto podjąć, jako, że lepsze jest wrogiem dobrego, tutaj lepsze jest następcą "starego" i przestarzałego.